Customers Page

The ARM supports a hosted Teams multi-tenant Direct Routing solution (ARM ‘customer’ entity feature). Microsoft Teams Hosters that implement the Microsoft recommended Super Trunk deployment model for multi-tenancy can use this feature and have each tenant represented by an ARM ‘customer’ entity. All ‘customer’ entities can traverse the same Peer Connection/VoIP Peer (SBC IP Group) on the AudioCodes Direct Routing SBC.

The logical entity ‘customer’ (Teams tenant) can be defined uniquely by either Prefix Groups or by a special tag assigned to a call, in the Policy Studio (Policy Studio Tag) if the operator wants to manage ‘customer’ entity DIDs in the Users page and use the Policy Studio and other ARM users’ capabilities. In this way, the ‘customer’ entity’s DIDs can be managed in both the Prefix Group or the ARM Users page (a combination of the two is also allowed).

The ARM also supports statistics and alarms related to the ‘customer’ entity.

ARM Routing capabilities support the ‘customer’ entity as a routing condition (specific ‘customer’ entities or all ‘customer’ entities). This also includes SIP header manipulations, required by Teams multi-tenancy, that can now easily be performed by the ARM (SIP ‘Contact’ header).

In addition, the ARM provides CAC capabilities for each Teams tenant. Since a Super Trunk (single IP Group for Teams) is provisioned on the SBC, individual CAC Profiles can't be applied in the SBC for each individual tenant that shares the Super Trunk. The ARM supports this capability by applying and performing CAC for each tenant that shares the same Super Trunk (Peer Connection/VoIP Peer/IP Group). This includes the following CAC capabilities:

Capability to define ingress CAC for logical customers under a VoIP Peer
Capability to define egress CAC for logical customers under a VoIP Peer
Capability to define CAC applicable for both directions

The following network diagram demonstrates this feature’s most common use case:

CAC Capabilities - Use Case

Multiple ‘customer’ entities (Teams tenants) can share the same ARM Peer Connection for Teams access (northbound).
Operators can share the same Service Providers/PSTN SIP trunks for multiple ‘customer’ entities (southbound).

Note that for redundancy purposes, multiple SBCs can be used leading to the same VoIP Peers, with local Peer Connections (IP Groups) on each SBC.

Connectivity to Microsoft using a ‘derived trunk’ setup.
A derived trunk can be considered a Super Trunk using only one (1) IP Group on each SBC (ARM Peer Connection).
Each unique ‘customer’ entity / Teams tenant making outbound calls can be identified by the FQDN in the ‘Contact’ or ‘From’ header, or by its DID.
Inbound calls from SIP trunks to the Teams ‘customer’ entity can be identified and associated with a specific ‘customer’ entity / Teams tenant by the destination DID (which can be managed either in the ARM Users page or by the Prefix Group).
This type of trunk eliminates the need for each ‘customer’ entity to have its own IP Group/Peer Connection with Sip:options requesting health checks.
Using the ARM for routing allows a very high number of ‘customer’ entities to be supported (as it becomes a logical entity).